The present invention relates to the field of business process management (BPM) systems and, more particularly, to a dynamically optimized distributed cloud computing-based BPM system.
Business process management (BPM) systems orchestrate the performance of the tasks that make up a workflow by various computing components and/or resources. Many conventional BPM systems operate under the premise that the computing components/resources utilized by the workflow are fixed or static. For example, when a workflow utilizes computing components/resources from other systems that are internal to the organization's enterprise computing network.
Many organizations are beginning to restructure their computing networks to incorporate a paradigm shift to a cloud computing environment and business models. In a cloud computing paradigm, cloud computing service providers utilize the Internet to provide computing resources and/or services to consumers in a service-oriented delivery model. For example, a business may utilize a third-party such as GOOGLE to provide email services instead of purchasing all the resources necessary to implement an email system in-house.
Use of a conventional BPM system 110 with a cloud computing environment 130, as shown in FIG. 1, illustrates some of the obstacles encountered with such a configuration. Initially, system 100 incurs additional overhead because the workflow engine 120 is unable to operate in a distributed fashion within the cloud computing environment 130. When the requestor 105 initiates 152 the performance of a workflow 125, the workflow engine 120 acts similar to a switchboard operator—retrieving 154 the workflow 125, sending 156 Step 1 data to cloud service 1 135, receiving 158 Output 1 from cloud service 1 135, sending 160 the Step 2 data and Output 1 to cloud service 2 140, and receiving 162 the final Output 2.
The larger the quantity/size of the data being exchanged between the workflow server 115 and the cloud services 135 and 140, the more time and/or bandwidth is required to perform the data transfers. This situation is further compounded when subsequent processing requires the output of a previous step, as shown in system 100. Since cloud service 2 140 requires Output 1 from cloud service 1 135, Output 1 must be sent 158 to the workflow server 115, which then passes 160 the Output 1 to cloud service 2 140.
Current approaches attempt to distribute the workflow 125 across different workflow engines 120. However, such an approach requires additional coordination among the workflow engines 120 as well as key business structures (i.e., service-level agreements) to adjudicate the transactions. In other words, use of multiple engines 120 alone does not avoid potential breakdown of the business process if a given subflow in a workflow cannot fulfill a given request or if performance is very slow.
Additionally, the workflow 125, typically written in a business process execution language (BPEL), is constructed using static conditions. That is, a provider and/or service are explicitly specified for each workflow step 127. This leads to a two-fold problem. Identifiers (e.g., Web site names and addresses) tend to be fluid in the dynamic cloud computing environment 130, which is problematic for applications and/or documents that statically encode a service identifier.
Further, the BPM system 110 does not take advantage of potential efficiencies and/or cost-savings afforded by the economy within the cloud computing environment. That is, the workflow engine 120 will always use cloud service 1 135 to perform step 1 127 even if time and/or money could be saved by using another service provider.